Data Management System

ABSTRACT

A method of collecting information about data and data handling processes from different types of applications in the context of a storage system is described. The retrieved information is presented to the user to illustrate the relationships among the data, for example, in the form of a data view illustrating the relationship among files, a storage view, illustrating the physical location at which the stored data is located, or a path view illustrating a particular path through the topology of the overall computing system and storage system. Also described are techniques for assuring the accuracy of backed up files.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is a Continuation Application of U.S.application Ser. No. 10/890,652, filed Jul. 13, 2004, which isincorporated by reference herein in its entirety for all purposes.

BACKGROUND OF THE INVENTION

This invention relates to systems for storing data, and in particular tostorage systems in which data is distributed among large numbers of harddisk drives or other storage media.

In a typical data storage network, data from many different applicationsis stored and retrieved, and it is difficult to track the relationshipsamong all of the data stored. For example, in an e-mail system, ane-mail server generates original data and provides it to a storagesystem. An archive server may archive some parts of the data todifferent parts of the storage system or to different storage systems.At the same time a replication server may replicate the original data todifferent storage, and the data may be backed up by a backup server toyet further storage. While each of these data handling processes operateon the data associated with that process in an appropriate manner, thearchive server, the replication server and the backup server eachoperate independently. Each has its own catalog or other mechanism formanaging how the data is stored and retrieved. Because of thedistributed nature of the system and the lack of consolidated catalogs,a user of a storage system typically cannot understand where data issituated in that storage system on a reliable basis.

Furthermore, the complexity of storage systems increases the probabilityof mistakes. In the example just described, some parts of the originaldata are not stored in the original storage, but instead have beenstored in the archive storage. As a result, a replication of theoriginal data will not contain the archive data. Thus the backup datawill also not contain the archive data. Therefore, when a user restoresdata from the backup, because the backup data is not a complete backupof the original data, not all of the original data will be restored. Allof this complexity makes managing the data in a coherent mannerdifficult and error-prone.

There are a few tools that help manage data in storage systems. Thesetools, however, do not address the issues mentioned above. Onecommercially available tool for use in management of a data storagesystem is provided by Veritas™ and referred to as SANPoint Control. Thissystem enables keeping track of the hardware devices and theirrelationships in a storage area network. Another commercially availabletool is provided by AppIQ and known as storage authority suite. Thissystem provides information about the hardware in the storage system,including hosts, bus adapters, switches, disk subsystems, etc. It alsoprovides capabilities for management of particular applications runningon the storage system, for example, Oracle databases, file servers, etc.

Another commercially available tool for use in storage systems is theAptare StorageConsole. This application software provides increasedreliability for backup and restore operations in a storage system. TheStorage Resource Broker from Nirvana is software that enables users ofsystems to share and manage filed stored in various locations. Itprovides various searching and presentation functions to enable users tofind particular files or information stored in various portions of largedata storage units.

Therefore, a system is needed which enables a user of the system to havea complete view of the data handling processes and the relationshipsamong processes for management of the data to reduce the chance of errorand improve the efficiency with which the data is managed.

BRIEF SUMMARY OF THE INVENTION

A system according to this invention provides a method for collectinginformation about data and data handling processes from different typesof data applications. This invention enables a user of the system toappreciate relationships among the data. It shows the data in a systemview and can illustrate the relationships among the data stored in thesystem with a graphical user interface. Preferably, in a storage systemhaving arrays of storage devices for storing information, a data manageraccording to this invention collects information about the relationshipsamong data and files stored therein and presents them to a user.

In a preferred embodiment, the graphical user interface provides theuser with the option of choosing from among three different views ofdata handling processes. These include a data view which illustrates howdata are related to each other, for example, by showing where aparticular file has been archived, replicated, or backed up. Preferablythe system also provides a storage view which illustrates how the datavolumes are related, for example, indicating which volumes in thestorage system have the original data, the archived data, replica data,and backed up data.

A third view for information in the storage system is referred to as thepath view. The path view illustrates how data is transferred through thesystem by various data handling processes, for example indicating whichports, switches, and storage handle particular files or other data.Furthermore, a system according to this invention provides a way todetect erroneous configurations of backup data by comparison of theamount of backup data with the amount of original data.

In one embodiment, a storage system having a replication server, abackup server, and an archive server further includes a data managerwhich tracks the stored data in at least two of three approaches. In oneapproach the stored data is tracked by presenting file namerelationships among the replicated, backup, or archived copies of thestored data. In the second approach, the physical locations within thestorage system, for example, in terms of volumes, are presented. In thethird approach, path information depicting the processes by which thedata arrived at its storage location are provided for the replicated,backup, or archived copies of the stored data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a system configuration for atypical storage area network including a data manager according to thisinvention;

FIG. 2 illustrates an archive catalog for an archive profile;

FIG. 3 illustrates an archive catalog for media information;

FIG. 4 illustrates an archive catalog for archived data;

FIG. 5 illustrates a backup catalog for a backup profile;

FIG. 6 illustrates a backup catalog for media information;

FIG. 7 illustrates a backup catalog for backup data;

FIG. 8 illustrates a replication catalog;

FIG. 9 illustrates a device catalog for a volume;

FIG. 10 illustrates a device catalog for storage;

FIG. 11 illustrates a device catalog for a file system;

FIG. 12 illustrates a device catalog for a path;

FIG. 13 illustrates a device catalog for an application;

FIG. 14 illustrates an archive catalog for an archive profile;

FIG. 15 illustrates an archive catalog for archived data;

FIG. 16 is a block diagram of one example of interconnections in astorage system;

FIG. 17 illustrates a data descriptor;

FIG. 18 illustrates a relationship descriptor for archived data;

FIG. 19 illustrates a relationship descriptor for backup data;

FIG. 20 illustrates a relationship descriptor for replication data;

FIG. 21 illustrates a relationship descriptor for application data;

FIG. 22 illustrates another relationship descriptor for archived data;

FIG. 23 illustrates a discovered configuration table;

FIG. 24 is an example of a discovered data table;

FIG. 25 is an example of a discovered relationship table;

FIG. 26 is an example of a GUI for a view of the data;

FIG. 27 is an illustration of a GUI for a view of the storage system;

FIG. 28 is an example of a GUI for a view of the path information;

FIG. 29 illustrates a process for data discovery;

FIG. 30 illustrates details of the Get Data From App process shown inFIG. 29;

FIG. 31 illustrates details of the Get Data From Backup process shown inFIG. 29;

FIG. 32 illustrates further details of the Get Data From Backup processshown in FIG. 29;

FIG. 33 illustrates details of the Get Data From Archive process shownin FIG. 29;

FIG. 34 illustrates further details of the Get Data From Archive processshown in FIG. 29;

FIG. 35 illustrates details of the Get Data from Replica process shownin FIG. 29;

FIG. 36 is a flow chart illustrating the steps for depicting the dataview;

FIG. 37 is a flow chart illustrating the steps for depicting the storageview;

FIG. 38 is a flow chart illustrating the steps for depicting the pathview; and

FIG. 39 is a flow chart illustrating the steps for checking backupoperations;

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a block diagram illustrating a hypothetical typical storagesystem as might be found in a complex computing environment. Most of thecomponents of the system shown in FIG. 1 are well known and thus arediscussed only briefly herein. The data manager 111, however, is notwell known and is explained in detail below.

The system shown in FIG. 1 includes two application servers 101 and 102.These servers run computer programs 101 a and 102 a to provide computingresources to users of the overall system. By execution of a storedprogram, the applications 101 a and 102 a generate data which is storedin the system illustrated in FIG. 1.

A replication server 103 replicates data to different storage systems orvolumes within the storage system to provide well known mirroringfunctionality. The replication server maintains a replication catalog106 as will be discussed below. Similarly, a backup server 104 providesdata backup functionality to enable restoration of data at a later dateshould there be hardware, software, or facilities failures. A backupcatalog 107 maintains a record of the backup operations, as alsodiscussed below.

Many large storage systems also include a hierarchical storage manageror archive server 105. Server 105 archives little used data from primarystorage areas to secondary storage areas to provide improved systemperformance and to reduce costs by maintaining the data on lower costmedia. As with the other servers, archive server 105 maintains anarchive catalog 108, also explained further below. Although servers101-105 have been discussed as though each were a standalone hardwareimplementation, this is not necessary. The servers may be implemented asseparate processes running on a single large computer, or as separateprocesses running on separate processors within a connected array ofcomputers.

The system shown in FIG. 1 also includes a storage area manager 109. Thestorage area manager is preferably a management server that manages theentire network depicted in FIG. 1, including the servers and the storagesystems 115, 116, and 117. The storage area manager maintains a devicecatalog 110 which is also discussed below. In essence, the storage areamanager can retrieve information from the switches 114, servers 101 . .. 105, storage systems 115-117, and the applications 101 a, 102 a.Storage area managers such as depicted in FIG. 1 are often implementedusing a standard protocol such as DMTF's CIM. Another way to implementthe storage area manager is to install an agent on the server and havethe agent collect information about the server locality and provide itto the storage area manager.

Although there are a variety of techniques commonly used to interconnectsystems such as depicted in FIG. 1, switches 114 have become anincreasingly popular connection technique. These switches are typicallyswitches based on Fibre Channel, Ethernet, or broadband technology.

The data received by the system or generated by the system as the resultof its server operations is stored in storage systems such as 115, 116,and 117. Each such storage system includes a disk controller 118, 119,and 120, respectively, as well as hard disk drives 118 a . . . 120 b forstoring data. For simplicity FIG. 1 illustrates only two disk drives perstorage system. In conventional implementations, however, hundreds ofdisk drives may be employed in the storage system. The disk controllers118, 119 and 120 control input and output requests issued from theservers to store and retrieve data from the hard disk drives.

For illustration three different types of storage systems are shown inFIG. 1. Storage system 115 is an enterprise Fibre Channel storagesystem. Such systems typically support SCSI as a data protocol betweenthe servers and the storage systems. The Nearline PC storage system 116operates in a similar manner, however, using ATA format hard diskdrives. Finally, the Network Attached Storage system 117 supports NFSand CIFS as file protocols. Thus, as depicted in FIG. 1, the system ofthis invention can be applicable to any type of storage system.

The components and systems shown in FIG. 1 are interconnected using twotechniques. A network 100 is provided, for example based onTCP/IP/Ethernet to provide “out of band” communications. The main datahandling, however, for the storage systems is provided by switches 114which allow interconnections of desired components as necessitated bythe particular operations to be performed.

The system of this invention adds an additional component 111, referredto herein as a data manager, to the overall system of FIG. 1. This datamanager communicates with the other components via the local areanetwork 100 and the switches 114. The data manager functions to collectdata handling process information from the applications and the dataapplications and present the results to a user. The results aretypically presented through a graphical user interface running on aconsole 113. The data manager maintains a data catalog. The data catalogenables the data manager to present to the user various “views” of thestorage system. For example, the data manager 111 and data catalogtogether enable a user to view information about the physical locationswhere various files are stored, the path by which the information wasstored, and other relationships among the data stored in the storagesystems 115, 116, and 117. The data manager 111 creates and manages datadescriptors, relationship descriptors, a discovered data table(discussed below) and a discovered relationship table (also discussedbelow). These tables are typically stored in local storage or networkstorage attached to the data manager. The data manager also uses adiscovery configuration table as discussed below. The data manageritself may be configured by the console 113. The data manager reliesupon catalogs created and stored throughout the system as designated inFIG. 1. These catalogs are discussed next.

FIG. 2 is a diagram illustrating an archive catalog for the archiveprofile. This catalog is included within the catalog 108 shown inFIG. 1. The catalog 200 shown in FIG. 2 describes which data is to bearchived, at what time, and to which storage. In the example shown inFIG. 2 the data is to be archived if it is not accessed within 30 days.The data to be archived is set forth as the Folder, and the media towhich it is to be archived is listed under Archive Media.

FIG. 3 illustrates an archive catalog for media information. Thiscatalog is also included within catalog 108 shown in FIG. 1. The examplein FIG. 3 illustrates that the Archive Media is actually an ArchiveFolder having a specified address associated with the specific server.FIG. 3 also indicates that the Folder has a maximum capacity as shown.

FIG. 4 is a diagram illustrating an archive catalog for archive data.This catalog is included within catalog 108 shown in FIG. 1. In theexample of FIG. 4, the indicated Source Data is shown as being archivedat the designated media location as an Archive Stream at the ArchiveTime shown in FIG. 4.

FIGS. 5-7 illustrate backup catalogs stored as catalog 107 in FIG. 1. InFIG. 5, an exemplary backup catalog for a backup profile is illustrated.This catalog describes how and when data is to be backed up. In theexample depicted, files under the folder designated by Source are to bebacked up to the Backup Media at the Backup Time stated. The Backup Typeindicates that all files are to be backed up, while the Next Backup Timeindicates the time and date of the next backup operation.

FIG. 6 is a diagram illustrating a backup catalog for media information.In a similar manner to FIG. 3, it illustrates the physical location ofthe particular media designated, as well as its capacity.

FIG. 7 illustrates a backup catalog for backup data. This catalogdescribes when and where data is backed up. In the example shown, twofiles as designated by Data Source have been backed up to the BackupMedia at the time shown.

FIG. 8 is a diagram illustrating a replication relationship between twodevices in the storage system, and is referred to as a replicationcatalog. This diagram provides additional information with regard to thereplication catalog 106 in FIG. 1. The replication catalog describes therelationship between two data storage locations, commonly known as LDEVsin the storage system. As shown by FIG. 8, the data in the PrimaryStorage is replicated to the Secondary Storage location. The Modeindicates whether the backup is to be synchronous or asynchronous.

FIG. 9 is a diagram illustrating a device catalog for a volume, withFIGS. 10-13 illustrating other device catalogs, all incorporated withincatalog 110 in FIG. 1. The volume catalog 207 shown in FIG. 9 includesthe volume identification, name, address, port, logical unit number,etc.

FIG. 10 illustrates a device catalog 208 for storage. This catalogprovides information about a storage system. As shown, the catalogincludes an identification, name, address, capacity, information aboutports coupled to the storage, etc.

FIG. 11 illustrates a catalog 220 for a file system. As shown there, thecatalog includes information about identification, physical volumelocation, file system type, free space, etc. Similarly, FIG. 12illustrates a device catalog for a path 221. This catalog includesidentification information and worldwide name identification.

FIG. 13 is a device catalog 222 for an application. As shown by FIG. 13,the catalog includes identification, application type, host name, andassociated data files.

FIGS. 14 and 15 illustrate an archive catalog for message basedarchiving. (FIGS. 2-4 illustrated archive catalogs for file-basedarchiving.) In message based archiving, the archiving is performed at anapplication level. For example, an e-mail server may store messages intodata files and an archive server then communicates with the e-mailserver to archive the messages themselves, instead of the data files. Inthese circumstances, the archive profile also indicates the name of aserver and the name of an application.

FIG. 14 illustrates an archive catalog 223 for an archive profile forthe case just described. As shown, the application is indicated with Aas well as the media name MN, and the media and timing information. Themedia information itself may be archived in the same manner as describedin conjunction with FIG. 3.

FIG. 15 illustrates an archive catalog 224 for archive data. Asmentioned above, the Source Data designates particular messages insteadof files. The Server Name and information about the media, data, andtime are also provided.

FIG. 16 depicts an exemplary system configuration which is used in theremainder of this application as an example to clarify the explanation.As shown in FIG. 16, several servers 230 are represented across theupper portion of the diagram, including an application server, anarchive server, a backup server, and a replication server. Two of theservers are connected with an Ethernet link. In the middle portion ofthe diagram, two switches 231 couple the various servers to variousstorage systems 232. The replication server is coupled to the EnterpriseStorage A to allow replication in that storage system. The applicationserver 230 stores data into LDEV1, while the archive server archivessome of that data into LDEV2. The replication server asks storage unit Ato replicate LDEV1 to LDEV3, and in response that event occurs. Thebackup server backs up data from LDEV3 to LDEV4.

In a conventional system without the data manager described inconjunction with FIG. 1, the various catalogs described above are allseparated and the user is not able to see the total relationships of thedata and files being managed by the storage system. The addition of thedata manager, however, allows communication among the various serversand the data manager, for example using scripts or other well knowninterfaces. By communication between the data manager and the variousservers these relationships may be discovered and presented to the useras discussed next.

FIG. 17 illustrates a sample data descriptor table 240. This tableillustrates information collected by the data manager 111 (see FIG. 1)about the data being handled by the storage system and the servers. Asshown in FIG. 17, the data descriptor table includes a considerableinformation for the particular unit of data discovered. It also includeslogical information about the data, including for example, the host nameassociated with that data, the path name, the “owner” of the data, anyrestrictions on access or rewriting of the data, the size, time ofcreation, time of modification, time of last access, and a count of thenumber of accesses. The data descriptor also includes information aboutthe mount point (where the data is located), the type of file systemassociated with the data, and the maximum size of that file system.Finally, the data descriptor includes physical information about thedata, including the storage system brand name (Lightning 9900), its IPaddress, its LDEV, etc. The physical information can also includeinformation about the maximum volume size, the level of RAID protection,etc.

Generally speaking, the logical information includes which server hasthe data, its logical location within that server, and access controlinformation, as well as size, and other parameters about the storeddata. Also generally speaking, the file system information describes thetype of file system in which the data is stored. The physicalinformation describes the storage system and the LDEVs on which aparticular file system has been created.

FIGS. 18-22 illustrate relationship descriptor tables to help establishthe relationships among the data stored in the storage system. FIG. 18is an example of a relationship descriptor table 241 for the archivesThe table includes information about a descriptor identification, itsrelationship to the original data, the original data descriptor, thearchive data descriptor, the archive time and the retention period thusfar. The relationship descriptor shows how the discovered data arerelated and assigns a unique ID (RID).

FIG. 19 provides a relationship descriptor for backup as shown there.Table 242 illustrates the original data of the specified addresses hasbeen backed up as data specified at that address. The backup date, time,speed, and other parameters are also maintained.

FIG. 20 is a relationship descriptor table 243 for replication. Thistable, in addition to the other information provided, maintains therelationship between the original and the replicated data based on theirglobal identification.

FIG. 21 is a relationship descriptor table 244 for an application. Asshown by this table, the e-mail server in the Trinity server has datasources specified by the designated global identification numbers.

As shown by table 245 in FIG. 22, there is a relationship descriptor forthe archive in a message based system. Because it would beresource-consuming to create a data descriptor and a relationshipdescriptor for each message, only the relationship between the originaldata and the archived data are identified in the case of message basedarchiving. Of course, if desired, a data descriptor could be created.

The data manager 111 also creates a number of tables based upon itsinteractions with the servers. These tables are referred to here asconsisting of a discovery configuration table 280 shown in FIG. 23, adiscovered data table 420 shown in FIG. 24, and a discoveredrelationship table 430 shown in FIG. 25. These tables are discussednext.

The discovered configuration table 280 shown in FIG. 23 shows from whichapplications and data applications the data manager has gatheredinformation. Each entry in the table, consisting of a row, specifies atype of discovered data, a server from which the information isgathered, an application or data application name, and ID and passwordinformation to gain access as needed. For example, in the first row oftable 280, an application program has collected information from serverE using the application SAMSoft, and this can be accessed using the IDand password shown at the end of the row.

FIG. 24 illustrates a discovered data table 420. This table providesmanagement information for the discovered data. As shown by the table,the data is uniquely identified by the combination of storage system,LDEV and a relative path name. Files stored in the storage system arestored using a file system. The relative path name provides a path nameinside the file system instead of a path name when the file system ismounted on a folder in the server. For example, assume LDEV1 is mountedon \folder1 at a server. Also assume there is a file with a path namewhich is \folder2\fileA. Thus the relative path name is File A.

FIG. 25 illustrates a discovered relationship table 430. This tablemanages the identifications of discovered relationships. In the exampledepicted, the relationship identified by RID 0002 is a backuprelationship indicating that the files having GIDs shown in the column“Source” were backed up as data identified by the “Destination” column.While backup, archive, and replication actions are associated with dataat two locations, the application itself only has source data. Thus“destination” is not applicable.

Using all of the tables discussed above and the various relationshipscreated, in a manner which will be discussed in detail below, the systemis capable of providing a comprehensive view of the relationships amongthe data stored in the affiliated storage systems. Exemplary graphicaluser interfaces for presenting these relationships to the user of thestorage system are shown in FIGS. 26, 27, and 28. As should beunderstood, other graphical user interfaces (GUI) can also be createdfor presentation to the user to enable a better understanding of thedata in the storage system. These interfaces will typically be of mostbenefit to an administrator of the data management system. Typicallythese interfaces will be presented on the console 113 shown in FIG. 1.Typical GUIs are discussed next.

FIG. 26 illustrates a “data view” GUI 250. In this exemplary GUI, thedata manager presents a view related to the data itself. In theembodiment depicted, the GUI has two parts, a data specifying panel onthe left hand side and an information panel on the right hand side ofthe figure. The data specification panel shows all of the applicationsand all of the data in the system that is being used by thoseapplications. For example, in FIG. 26, the specification panel listse-mail applications and within those applications an e-mail server A.That e-mail server has a number of files, shown in the example as A, B,and C. The user has chosen file A. In response the GUI is illustratinginformation about that file in the right hand panel shown in FIG. 26.This panel illustrates the relationship information about the dataassociated with file A. As shown at the top of the panel, the server andfile location are shown, as well as all archived, replicated, and backedup copies of that file. As illustrated, file A has been archived byserver B at the designated location, has been replicated by server C atthe designated location, and has been backed up by server D at thedesignated location. By clicking on the “Details” designation, the usercauses the system to retrieve “deeper” information about that data, forexample it's size, the time of the event, or other information providedin the descriptor tables discussed above, and that data will bepresented on the GUI.

FIG. 27 illustrates the GUI for a “storage view” of the data. The lefthand panel shown in FIG. 27 corresponds to that discussed in FIG. 26,enabling the user to select a particular file. In the same manner asdescribed there, the user selected file A, and thus the right hand panelof the storage view 260 is illustrating information about file A. Thatpanel shows the LDEV and storage system where the original data isstored, as well as the LDEVs and the storage systems in which all of thedata related to the original data are stored, as well as therelationships among those locations. For example, as shown in the upperportion of the right hand panel, the replica, archive, and backuprelationships are illustrated.

FIG. 28 is a third GUI enabling the user to more easily understand thelocation of various data in the storage system and the path by whichthat data is being handled. FIG. 28 illustrates the “path view” GUI. Aswith the above FIGS. 26 and 27, the left hand side of the GUI 270enables the user to select the particular file, while the right handside depicts the topology map of the servers, switches, storage systems,and LDEVs for the original data, and for data related to the originaldata. This diagram also illustrates how data is transferred in thetopology. To simplify the diagram, across the upper portion of the righthand panel in FIG. 28 are a series of “buttons.” By clicking on one ofthese buttons, the screen will show a path through which data istransferred by the specified relationship.

The preceding discussion has discussed the various tables created andused by the data manager 111, and the graphical user interface forpresentation of that data to a user of the system. The remaining portionof this specification discusses the manner in which the system operatesto establish those tables and present the graphical user interfaces.

FIG. 29 is a flowchart illustrating a preferred embodiment of the datadiscovery process by the data manager shown in FIG. 1. The process isinitiated by a user at the console 113 shown in FIG. 1. At a first step290 the data manager retrieves an entry from the discovery configurationtable shown in FIG. 23, unless that entry is a replication entry. Ifthere is a non-replication entry the flow proceeds immediately downwardas shown in FIG. 29. On the other hand, if there is no new entry, thenthe data discovery process retrieves a replication entry from thediscovery configuration table as shown by step 296. Assuming there is anew entry, the data manager checks the type of server and executes oneof three procedures 293, 294 or 295, depending upon the type of server,as shown by the loop in FIG. 29. After that entry is retrieved theprocess reverts back to step 290 to be repeated as many times as isnecessary to retrieve all of the entries from all of the servers. Thedetails of the particular “get data” procedure 293, 294, or 295 arediscussed below. Once these procedures are completed, then the systemreverts to checking the replication entries as shown by step 296.Assuming there are replication entries, then the procedure follows step298, which is also discussed later below. Once all of the entries havebeen retrieved as shown at step 297, the data discovery process ends.

FIG. 30 illustrates in more detail the process flow for getting datafrom an application as shown by block 293 in FIG. 29. The data managerfirst connects to the SAM server via the network. It uses anidentification and password in the discovery configuration table for theconnection 300. It then retrieves a list of applications from the SAMserver 301, and for each application a list of data files from thatserver as shown by step 302. As shown by step 303, for each data file onthat list, the data manager gets a file system name in which the datafile is stored in the SAM server. Then, as shown by step 304, for eachfile system a storage name and an LDEV on which the file system iscreated are also retrieved from the SAM server. Next, for each uniqueset (a name of a storage system, an LDEV, a data file relative pathname) the data manager creates a new entry in the discovered data tableand allocates a new global identification to that if there is notalready an entry for that set. As shown by step 306, for each such GID,a data descriptor is created. Then, as shown by step 307, for each datadescriptor, the data manager will retrieve logical information, filesystem information, and physical information from the SAM server andfile that information into the data descriptor table. Then, as shown bystep 308, for each application a new entry in the discoveredrelationship table is created and a new RID is provided if there is notalready an entry for that application. Finally, as shown by step 309,for each RID the relationship descriptor for the application and thefile information is then created. Once these steps are completed, theprocess flow returns to the diagram shown in FIG. 29.

FIG. 31 illustrates the process of retrieving data from the backupserver, illustrated in FIG. 29 as step 294. Once this process isinvoked, the operation is similar to that described in FIG. 30. Inparticular, the data manager first connects to a backup server via thenetwork. It uses the ID and password information from the discoveryconfiguration table for the connection, as shown in step 320. It alsoconnects to the SAM server in the same manner, as shown in step 321. Atstep 322, the data manager retrieves a list of backup profiles from thebackup server. As shown by step 323, for each such backup profile thedata manager obtains a list of backup data from the backup server. Then,at step 324, for each backup data, the data manager retrieves a filesystem in which the backup stream is stored from the backup server.Next, as shown by step 325, for each unique file system a storage nameand an LDEV on which the file system is created, are retrieved from theSAM server. Then, at step 326, for each unique set (name, LDEV, andbackup stream relative path name) a new entry is created in thediscovered data table and a new GID is allocated if there is not alreadyan entry for that set. Next, at step 327, for each GID a data descriptoris created. Then, as shown at step 328, for each data descriptor logicalinformation, file system information, and physical information from theSAM server is retrieved and provided to the data descriptor table.

FIG. 32 illustrates the process following step 328. As shown in FIG. 32,for each backup data, the data manager obtains a list of the datasources from the backup server at step 329. Then for each unique datasource, a file system in which the data source is stored is alsoretrieved from the backup server at step 330. At step 331, for eachunique file system, the data manager retrieves a storage name and anLDEV on which the file system is created from the same server. Then, atstep 332, for each unique set of storage name, LDEV, and data sourcerelative path name, a new entry is created in the discovered data table,and a new GID is allocated if there is not already an entry for thatset. Then at step 333, a data descriptor is created for each GID. Atstep 334, for each data descriptor, logical information, file systeminformation, and physical information is retrieved from the same serverand filled into the data descriptor table. Then at step 336, for eachbackup data, a new entry is created in the discovered relationship tableand a new RID is allocated if there is not already an entry for thatbackup data. Finally, at step 337 for each RID, a relationshipdescriptor for the backup information is created and this is filled intothe discovered data table. That step concludes operations for the getdata from backup step shown generally as step 294 in FIG. 29.

FIG. 33 illustrates the details behind the step of getting data from thearchive, represented by step 295 in FIG. 29. As described above, theseoperations are similar to the other get data operations discussed in theprevious few figures. The process begins with step 340 in which the datamanager connects to the archive server using an ID and passwordinformation. It also connects to the same server with the ID andpassword information as shown by step 341. At step 343, it obtains alist of archive profiles, and at step 344, for each archive profile itobtains a list of archive data from the archive server. At step 345 foreach archive data, it retrieves the file system in which the archivestream is stored from the archive server. Then for each unique set of astorage name, an LDEV, and an archive stream relative path name, a newentry is created in the discovered data table and a new GID is allocatedif there is not already one for that set. Next at step 348, for each GIDa data descriptor is created, and finally at step 349, for each suchdata descriptor logical information from a file system information andphysical information from the SAM server is filled into the datadescriptor table. The process then continues with FIG. 34.

As shown by step 350, for each archived data, a list of data sources isretrieved from the archive server. Then for each unique data source, afile system for that data source is retrieved from the archive server,as shown by step 351. Then, for each unique file system, the storagename and LDEV on which the file system is created are retrieved from theSAM server. Next, at step 353, for each unique set of a storage name, anLDEV, and a data source relative path name, a new entry is created inthe discovered data table and a new GID is allocated if there is notalready one for that set. Then a new data descriptor is created for eachGID and for each such data descriptor, logical information, file systeminformation, and physical information is retrieved from the SAM serverand filled into the data descriptor table as shown by step 355. Then,for each archived data, a new entry is created in the discoveredrelationship table and a new RID is allocated if there is not alreadyone for that data. Finally, a relationship descriptor is created forthat RID and filled in to the data discovery table.

The process for getting data from the replica servers is similar to thatdescribed above. It is illustrated in FIG. 35. The process follows aflow of connecting to the replication server with an ID and password360, connecting to the SAM server 361, and obtaining a list ofreplication profiles from the replication server 362. Then for eachreplication profile, selected information is retrieved at step 363, andfor each such replication set, the data is located that is stored inthese volumes at step 364. Then for each found data set a new entry iscreated in the discovered relationship table, and for each such new RIDa relationship descriptor is created and the information filled into thetable at step 366. This completes the description of the processesinitially shown in FIG. 29. Next, the techniques for showing the variousdata, storage and path view. The steps for showing a data view areillustrated by the flow chart of FIG. 36. To show the data view, thedata manager receives a server name, an application name, and a datafile from the GUI, as shown by step 370. As discussed above, thisselection will typically be made by the user choosing an appropriateentry in the left hand panel of the GUI. Then, as shown by step 371, theGID for the specified data is retrieved from the discovered data table,and at step 372, a list is retrieved of all RIDs that contain the GIDfrom the discovered relationship table. If there are none, then thefound GIDs may be displayed, as shown by step 376. If there are RIDs,then for each such RID, the GIDs and the destination are also retrievedfrom the discovered relationship table as shown by step 374. Once thisis completed, the display is produced as shown by step 376.

FIG. 37 illustrates the steps for showing a storage view in the GUI. Ina manner similar to that described with FIG. 36, the user selectsvarious information as shown in step 380, and the GID for the specifieddata is retrieved from the discovered data table. The flow of operationsthrough steps 382, 383, 384, and 385 matches that from FIG. 36. Then, atstep 386, for each found GID the data manager finds the storage systemand LDEVs in which the data specified by the GID is stored, and showsthe storage as a storage icon on the screen and the LDEV as LDEV iconson the screen. Next, as shown by step 387, the LDEV icons areinterconnected by relationship indicators for each found RID.

FIG. 38 is a flow chart illustrating the manner in which the path viewGUI is created. Steps 390-395 are the same as those described above forthe data and storage views. At step 396, for all of the found GIDs andRIDs find the related servers, switches, storage systems, and LDEVs thatare related to the data or data applications specified by these foundGIDs and RIDs. Following this step, the physical topology map for allthe found hardware components is displayed at step 397, and relationshipbuttons are added at step 398. At step 399, if a button is pushed, thenthe system shows the data path by which the designated data istransferred, which information is provided by the SAM server.

FIG. 39 is a flow chart illustrating another feature provided by thesystem of this invention. FIG. 39 provides a technique for detecting amisconfiguration of a data backup by comparing the size of the backupdata with the size of the original data. The process shown in FIG. 39may be invoked by the user through the storage console 113 shown inFIG. 1. Upon invocation, the system receives a server name, anapplication, and a data file from the GUI as shown by step 400. Then theGID for the specified data is retrieved from the discovered data tableand the list of RIDs that contain that GID are retrieved from thediscovered relationship table. This process is repeated until all RIDsand GIDs are retrieved as shown by steps 403-405. At step 406 acalculation is performed for each GID with a full backup to determinethe size of the backup stream. The size of the data files for thatapplication are then computed at step 407. At step 408, if the amountsmatch, a successfully completed message is displayed at step 409, whileif the amounts do not match, an error is displayed at step 410. Uponreceipt of the error the user can then either reperform the backup ofinvestigate the error and resolve it in some other manner.

The technology described has numerous applications. These applicationsare not restricted to backup, archive, replication, etc. The inventioncan be applied to other applications or custom applications in whichdata is to be analyzed and relationships determined. The invention isalso not limited to files or data in the local file system or localserver. Instead, the invention can be applied to volumes in storagesystems and objects in object based storage devices, or files in networkattached storage systems. It can be applied to volumes, and to storagesystems which replicate volumes by themselves. The data manager in suchan application can determine from the storage system or the replicationserver how the volumes are replicated and create a data descriptor foreach volume without path information, and also create a relationshipdescriptor by using the replication relationship. In the case of networkattached storage, the data is uniquely identified by an IP address, anexported file system and a relative path name.

While LDEV has been user herein to identify the uniqueness of data,other approaches may be used. The data manager may calculate a hashvalue for each data. Then the data manager can retrieve the logicallocation and physical location of such data from a SAM server. If thedata are related to different locations, then the data manager cancreate a relationship descriptor for these data which indicates that thedata are identical (in the case of duplicate hash values). This enablesthe user to see how many replications of data are present on the storagesystem and to determine which data can be deleted.

By checking a hierarchy of relationships among data and performanceinformation from the data processing, the data manager can also detectat what location in the hierarchy a performance bottleneck exists. Insuch a case, the data manager which retrieves performance informationfor each relationship and determines if those numbers are restricted byphysical resources or disturbances caused by other data processing orapplication software. The data manager also provides users a way tosearch for data and relationships among data by specifying some portionof the data. If the data manager receives such a request, the datamanager can find data descriptors and relationship descriptors thatinclude the specified information and provide it, for example asdescribed on a graphical user interface.

Although the invention has been described in detail above with respectto a preferred embodiment, it will be appreciated that variations andalterations may be made in the implementation of the invention withoutdeparting from its scope as shown by the appended claims.

1. In a data management system coupled to a first server which processesdata to be stored in a first storage system, a second server whichprovides a copy of the stored data to be stored in a second storagesystem, and a third server which provides another copy of the storeddata to be stored in a third storage system, a data management methodcomprising steps of: collecting from the second server, informationabout the copied data stored in the second storage system; collectingfrom the third server, information about the another copied data storedin the third storage system; creating relationship informationindicative of associations among the stored data in the first storagesystem, the copied data stored in the second storage system and theanother copied data stored in the third storage system; and presentingthe relationship information associated with stored data identified in auser's request.
 2. The data management method of claim 1, wherein therelationship information include location information and/or pathinformation.
 3. The data management method of claim 2, wherein the pathinformation include port and switch information.
 4. The data managementmethod of claim 1, wherein the relationship information include physicallocation information and/or virtual location information.
 5. The datamanagement method of claim 1, wherein the presenting the relationshipinformation includes displaying the relationship information bygraphical user interface.
 6. The data management method of claim 1, thefirst server includes an application server.